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ABSTRACT 

A system is proposed which will support computer gaming 
in real-time. This system will, when combined with the user's 
Control Program, monitor all of the functions necessary to 
provide real-time man/machine interaction with the game. The 
formal definition of a programming language (RTGS Control 
Program Commang Language) is given; this language, supplemen- 
ted by Fortran IV and IBM OS/360 Assembler Language is used 
for coding the user's Control Program. Plans for implementa- 
tion on an IBM System/360 Model 67 are discussed and a sample 
program is given. 
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FOREWORD 



The proposal made here is for a real-time system for 
gaming. The system encompasses a source language adaptable 
to gaming and a compiler and monitor system for generating 
and running games. The aim is to provide the capability for 
gaming in real-time with dynamic interaction between the 
players and the computing machinery. This is to be done 
without the requirement for tedious attention to the details 
of real-time programming or a special hybrid computer instal- 
lation. The system is designed to run on a general purpose 
digital computer with a tele-processing capability. 

The specific installation for which the pilot system 
was designed is the IBM OS/360, Model 67 installed at the 
Naval Postgraduate School. The system has not, at this time, 
been fully implemented; however, the feasibility of such a 
system has been investigated by partial implementation. 

The thesis presents a formal definition of the system. 

It goes into some detail on the individual commands; however, 
it is not meant to serve as a users 1 manual for the system. 

Most of the details of generating and running the system were 
intentionally left out since they are mostly a function of 
the final implementation. 

The present intention of the author is to continue with 
the implementation and provide a full scale system. It is 
anticipated that when the system is available, a Technical 
Paper will be published with the details of the implementation. 
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CHAPTER I 



INTRODUCTION 

In recent years, gaming and simulation techniques have 
emerged as powerful tools to aid in the solution of problems 
hitherto unsolvable by conventional techniques. Gaming and 
simulation techniques are used to model "real world" situa- 
tions in order to test the sensitivity of various parametric 
changes. In this manner it is possible to try various 
courses of action and make observations as to which are 
best . 

Programming techniques for gaming vary markedly, being 
mostly a function of the type of computing machinery upon 
which the game will be run. At one end of the scale is the 
completely "self-contained" game, programmed to run on a 
general purpose digital computer with no human intervention 
during the play of the game. At the other end of the scale 
is the game programmed for hybrid computing systems or 
training devices which depend verv heavily on "man-machine" 
interaction for their operation. These broad categories of 
programming techniques will be discussed separately. 

Self Contained Games 

Self contained games do not require any intervention 
while they are running. In this type gaming there are two 
basic programming techniques employed; time-step gaming and 
event-store gaming. 
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Time-step game . The time-step game is, as its name 
implies , a game in which the play takes place in discrete 
frames of time. Each frame of time represents a cycle in 
the game. During each time cycle, the elements of the game 
are tested and decisions are made as to how they interact. 
The elements are then updated to represent their new posi- 
tions for going into the next cycle. The clock is advanced 
an amount equal to the cycle time and the game continues in 
the same manner until some pre-determined number of cycles 
have been processed or until some condition occurs. As the 
game proceeds, various parameters may be measured, statis- 
tics collected, tests conducted, etc.; the results are re- 
corded for outputting after the game is completed. One of 
the major drawbacks of this type of game is that it is 
essentially discrete in its representation of the "real- 
world" and the only way to make it appear continuous is to 
make the time cycle very short with respect to the factors 
which are being measured. If this is not done, the resolu- 
tion of the results may be unacceptable. For example, in 
a system where minutes are important it may be necessary 
to use the second as the basic time unit in order to get 
smooth results; however, each time-cycle usually involves 
a complete, or at least partial, updating of all of the 
force-units in the game as well as all other variable fac- 
tors, a large portion of which do not effect the outcome of 
the game within the current cycle. The result is that, in 
some games , much unnecessary computation and manipulation 
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of data is done. Consider the scenario illustrated in Fig- 
ure 1 which represents a small segment of a theater-of- 
operations . 




Figure 1 

Ship A is searching north along track A using a radar 
set that detects according to some probabilistic range law. 
Ship B is proceeding west along track B and will eventually 
come into the radar envelope of ship A. It is desired that 
measurements of the range at which the first detection occurs 
and the relative positions of the ships at that time be re- 
corded. If we assume that the maximum relative closing rate 
of the two ships is fifty knots and that we must have the 
range measurement accurate to within one hundred yards , then 
the longest period of time that we can allow between meas- 
urements is .01 hours or roughly thirty six seconds. Hence, 
if the above situation were part of a time-steo game, the 
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time-cycle might be set at, say, thirty seconds. The worst 
resolution in distance that could be expected under these 
circumstances would be about one hundred yards, with improve- 
ment at relative closing rates smaller than fifty knots. Now 
assume that the two ships start at positions twenty five 
miles apart closing at a rate of seven knots and that the 
average detection range on shin A's radar is eleven miles. 

It will take about two hours for ship B to close to this 
average detection range. With a time-cvcle of thirty sec- 
onds , the expected number of cycles before there is any ac- 
tivity on the radar is two hundred and forty plus or minus 
a few to account for the probabilistic effect in radar detec- 
tion range. During each cycle, ship A and ship B will be 
advanced thirty seconds along their respective tracks. The 
probabilistic range law will be applied to determine if the 
detection has occurred, the necessary factors, if any, will 
be recorded and the clock will be advanced thirty seconds - 
- the game is now ready for the next cycle. In this partic- 
ular instance the time-step procedure is not the best way 
to program the situation. 

There are, on the other hand, games where a discrete 
time-step is the best way to operate. Specifically, games 
in which time is not an important consideration, but rather, 
the order in which things occur. For example, in the board 
game of Chess, the players alternate at making moves and 
time is not a factor. This game could be programmed as a 
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time-step game where "time" is actually a misnomer and each 
cycle would consist of a decision and move by one of the 
players . 

Event-store game . Many games that involve force-units 
moving in a non-discrete manner can be broken up into a 
number of different events which occur with a varying amount 
of time between. For example, in the simple two-shiD sce- 
nario just given there is just one event, that of making a 
detection . 

When a game can be broken up into events occurring at 
some determinable time, it may be best to use an event-store 
type game. The primary difference between an event-store 
game and a time-step game is that in the former a time cycle 
is not of fixed length. Rather, the occurrence of specific 
events in the game determines the length of time between 
cycles. At the completion of one cycle, it is determined 
at what time the next significant event is to occur in the 
game; the clock is then advanced directly to that time and 
the necessary activity associated with that event is oer- 
formed. Parameters of the game which are not associated 
with that event are not changed. 

In the example given, an event could be defined, and a 
routine provided, to record the distance from shio A to ship 
B and the relative positions of the ships. Then at the be- 
ginning of the situation a mathematical computation could 
be performed to determine the exact time at which the detec- 
tion would occur; an event could be stored for execution at 
the computed time. Since, in this case, that event would be 
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the only one stored, the clock could immediately be advanced 
to the detection time and the routine would be executed, re- 
cording the necessary data. In this example, considerable 
computational effort would have been saved. 

The price that must be paid for this efficiency is 
usually complexity. Event-store games are considerably more 
complicated than time-step games. 

In both of these game types, one consideration is get- 
ting the games into and out of the computing machinery as 
soon as possible. As soon as all the actions or events due 
at a certain time are accomplished, the "game-clock" is ad- 
vanced either a fixed amount as in the time-step game or to 
the next event- time as in the case of the event-store game. 
The computations are performed, etc. Several replications 
of a game that may represent hours of real time may thus be 
compressed into minutes or even seconds of actual machine 
running time. In order to program a game of this type it is 
necessary to load the decisions that are to be made in all 
situations into the program ahead of time. This is either 
done in the form of mathematical functions or tables. Then, 
when a decision point is reached it can be immediately re- 
solved. There is usually no "human" intervention in the 
game once it has begun. 

Interaction Games 

It may be the case that one of the factors to be meas- 
ured by the game is the effect of human decision making in 
the face of the available information and it may not be a 
simple matter to characterize all of the possible conditions 
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ahead of time so that the resulting decisions can be tabu- 
lated. A good example of this sort of game is the game of 
Chess. There are so many combinations of moves and counter- 
moves in this game that it would be infeasible, if not im- 
possible, to store in advance the decision to be made for 
every situation. It may be more feasible to wait until cer- 
tain situations develop and then let a "human" decision be 
made. Another situation where it would be useful to have 
"man-machine" interaction is the case where the game is be- 
ing used as an aid to the teaching of decision-making. 

Consider the scenario of a Naval ship such as a de- 
stroyer searching for a submarine. It is desired that cer- 
tain newly proposed tactics for the surface ship be evalua- 
ted. The use of "self-contained" wargaming techniques in- 
volve programming the basic scenario with the application 
of the new tactics as a variable. Then the game is run sev- 
eral times with slight variations in the tactics; possibly 
with several replications on each, in order to collect 
statistical data on how effective the new tactics could be 
expected to be in the particular environment. Once the pa- 
rameters of the game have been set, it is not possible to 
make any changes. This type of wargaming is excellent for 
the evaluation of new tactics; however, when used as a train- 
ing device it loses much of its appeal since the players 
must make their decisions in a block before the run and then 
observe the results after the fact. There is no dynamic 
interaction, and hence, sometimes very little feel for what 
went on in all of the intermediate stages. 
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CHAPTER II 



REAL TIME GAMING SYSTEM 

The gaming system proposed here is aimed at filling the 
gap between strict self-contained games run purely for the 
evaluation of strategies and tactics and the hybrid training 
devices built specifically for the purpose of training people 
in decision-making. The class of games which this system is 
designed to handle are those games in which most of the deci- 
sions are made dynamically by the players in real-time. In 
this sort of situation, the computing machinery functions 
primarily as an umpire and bookkeeper, making sure that the 
decisions made by the individuals are legal in the framework 
of the game, and that all of the proper data and statistics 
are collected as the play of the game proceeds. 

The aim of the system is to provide a real-time gaming 
capability for a general purpose digital computer with a 
minimum of effort on the part of the programmer. Specif- 
ically, the system described here is proposed for implemen- 
tation on the International Business Machines System/360 
Model 67 installed at the Naval Postgraduate School. The de- 
tails of machine configuration are listed in Appendix H. 

In a real-time system a great deal of effort must be de- 
voted to general bookkeeping functions such as : event man- 

agement, input/output, maintaining force-unit status informa- 
tion, and collecting data. Many of these functions are the 
same from one game to the next with the only significant 
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difference being the flow of logic associated with the var- 
ious decisions in different game scenarios. The major fea- 
tures of the system are discussed in the following sections. 
Batch processing compatability 

One important attribute of a real-time system which is 
to be run on computing machinery normally devoted to other 
tasks, is that it run with a minimum of interference to 
those tasks. The proposed system is designed to operate in 
a multi-programming environment capable of processing sev- 
eral users' programs at the same time. In this manner, the 
Real Time Gaming System can operate concurrently with the 
normal batch processing stream. The amount of central proc- 
essor time that is required by the system will usually be 
proportionately quite low compared with the total time that 
the game will be running on the system. Hence, it is to be 
expected that the degradation to normal batch service will 
be quite low. 

Input/output management 

The primary device for input/output for this system is 
the standard tele-processing remote terminal provided by the 
computing machinery configuration. Each of the olavers , as 
well as the umpire, is stationed at one of these terminals 
and it is from this unit that he receives information and 
makes decisions as the play of the game proceeds. 

Under control of the generated Control Program, infor- 
mation can be freely passed back and forth among players and 
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